Skip Headers

Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# Datafile Media Recovery with RMAN

The concept of datafile media recovery is the application of online or archived redo logs or incremental backups to a restored datafile in order to update it to the current time or some other specified time. Use the RMAN `RECOVER` command to perform media recovery and apply logs or incremental backups automatically.

## RMAN Media Recovery: Basic Steps

If possible, make the recovery catalog available to perform the media recovery. If it is not available, or if you do not maintain a recovery catalog, then RMAN uses metadata from the target database control file. If both the control file and recovery catalog are lost, then you can still recover the database—assuming that you have backups of the datafiles and at least one autobackup of the control file.

The generic steps for media recovery using RMAN are as follows:

1. Place the database in the appropriate state: mounted or open. For example, mount the database when performing whole database recovery, or open the database when performing online tablespace recovery.

2. To perform incomplete recovery, use the `SET` `UNTIL` command to specify the time, SCN, restore point, or log sequence number at which recovery terminates. Alternatively, specify the `UNTIL` clause on the `RESTORE` and `RECOVER` commands.

3. Restore the necessary files with the `RESTORE` command.

4. Recover the datafiles with the `RECOVER` command.

5. Place the database in its normal state. For example, open the database, or bring the recovered tablespaces online.

Figure 3-1 illustrates an example of RMAN media recovery using data from the RMAN repository. The repository in this example is stored in a recovery catalog. The contents of the recovery catalog have been synchronized with the record of backups in the control file.

The DBA enters the following commands in the RMAN client:

    RESTORE DATABASE;
    RECOVER DATABASE;

RMAN then queries the repository, which in this example is a recovery catalog. RMAN then decides which backup sets to restore, and which incremental backups and archived logs to use for recovery. A server session on the target database instance performs the actual work of restore and recovery.

Figure 3-1 Performing RMAN Media Recovery

Description of "Figure 3-1 Performing RMAN Media Recovery"

See Also: Chapter 7, "Advanced RMAN Recovery Techniques" for detailed restore and recovery procedures "Control File and Server Parameter File Autobackups" Oracle Database Backup and Recovery Reference for `RESTORE` syntax Oracle Database Backup and Recovery Reference for `RECOVER` syntax

## Mechanics of Recovery: Incremental Backups and Redo Logs

If RMAN has a choice between applying an incremental backup or applying redo to the restored datafiles to meet a recovery objective, then it always chooses an incremental backup. If overlapping levels of incremental backup are available, then RMAN automatically chooses the one covering the longest period of time.

RMAN does not need to apply incremental backups to a restored level 0 incremental backup: it can also apply archived logs. RMAN restores the datafiles that it needs from available backups, applies incremental backups to the datafiles if they are available, and then applies archived logs.

### How RMAN Searches for Archived Redo Logs During Recovery

If RMAN cannot find an incremental backup, then it looks in the repository for the names of archived redo logs to use for recovery. The database records an archived log in the control file whenever one of the following occurs:

- The archiver process archives a redo log

- RMAN restores an archived log

- The RMAN `BACKUP` `AS` `COPY` command copies a log

- The RMAN `CATALOG` command catalogs a user-managed backup of an archived log

If you use a recovery catalog, then RMAN propagates archived log data into the recovery catalog during resynchronization, classifying archived logs as image copies.

You can view the log information using the `LIST ARCHIVELOG` command orthe `V$ARCHIVED_LOG` control file view.

During recovery, RMAN looks for the needed logs using the filenames specified in the `V$ARCHIVED_LOG` view. If the logs were created in multiple destinations or were generated by the `BACKUP` `AS` `COPY`, `CATALOG`, or `RESTORE` commands, then multiple, identical copies of each log sequence number exist on disk. All copies of a log sequence number listed as `AVAILABLE` are candidates for use in recovery, regardless of how or where they are stored.

Logs that have been deleted or uncataloged through RMAN are not considered available for recovery. For example, assume that the database archives log 100 to directories `/dest1` and `/dest2`. The RMAN repository indicates that `/dest1/log100.arc` and `/dest2/log100.arc` exist. If you delete `/dest1/log100.arc` with the `DELETE` command, then the repository indicates that only `/dest2/log100.arc` is available for recovery.

If the RMAN repository indicates that no copies of a needed log sequence number exist on disk, then RMAN looks in backups and restores archived redo logs as needed to perform the media recovery. By default, RMAN restores the archived redo logs to the flash recovery area, if one of the archive log destinations is set to USE_DB_RECOVERY_FILE_DEST. Otherwise, it restores the logs to the first local archiving destination specified in the initialization parameter file. You can run the `SET` `ARCHIVELOG` `DESTINATION` command to specify a different restore location. If you specify the `DELETE` `ARCHIVELOG` option on `RECOVER`, then RMAN deletes the archived logs after restoring and applying them. If you also specify `MAXSIZE` `integer` on the `RECOVER` command, then RMAN restores archived logs until the disk space allowed by `MAXSIZE` is consumed, then applies redo from the logs and deletes the restored logs to free space, until there is room enough to restore another archived log. RMAN continues restoring, applying and deleting logs, within the `MAXSIZE` limit, until recovery is complete.

### RMAN Behavior When the Repository Is Not Synchronized

If an archived log is deleted from disk but is still listed in the RMAN repository, then RMAN does not perform automatic failover during recovery. For example, if the repository indicates that `/dest1/log100.arc` is on disk when in fact this log was deleted using an operating system command, and if RMAN attempts to apply this log file during recovery, then recovery terminates with an error. RMAN does not automatically attempt to apply other copies of log 100 that are listed as available in the repository.

This situation can sometimes occur when you delete an archived log with an operating system utility and then fail to run `CROSSCHECK` to synchronize the repository with the actual disk contents. If you run a `CROSSCHECK`, then the RMAN repository is synchronized, and recovery can proceed by applying available copies of the log or restoring a backup of the log if no disk copies are available.

See Also: Oracle Database Backup and Recovery Reference for `CROSSCHECK` syntax

## Incomplete or Point-In-Time Recovery

RMAN can perform either complete or point-in-time recovery (also called incomplete recovery). You can specify a time, SCN, restore point, or log sequence number as a limit for incomplete recovery with the `SET` `UNTIL` command or with an `UNTIL` clause specified directory on the `RESTORE` and `RECOVER` commands. The easiest method is run the `SET` `UNTIL` command before issuing the `RESTORE` and `RECOVER` commands. After performing incomplete recovery, you must open the database with the `RESETLOGS` option.

See Also: Oracle Database Backup and Recovery Reference for the `UNTIL` clause syntax

## Tablespace Point-in-Time Recovery

Recovery Manager automated Tablespace Point-in-Time Recovery (TSPITR) enables you to recover one or more tablespaces to a point in time that is different from that of the rest of the database. RMAN TSPITR is most useful in these cases:

- To recover from an erroneous drop or truncate table operation

- To recover a table that has become logically corrupted

- To recover from an incorrect batch job or other DML statement that has affected only a subset of the database

- In cases where there are multiple logical schemas in separate tablespaces of one physical database, and where one schema must be recovered to a point different from that of the rest of the physical database

- For VLDBs (very large databases), even if a full database point-in-time recovery would suffice, you might choose to do tablespace point-in-time recovery rather than restore the whole database from a backup and perform a complete database roll forward

Similar to a table export, RMAN TSPITR enables you to recover a consistent data set; however, the data set is the entire tablespace rather than a single object.

See Also: Chapter 8, "RMAN Tablespace Point-in-Time Recovery (TSPITR)" to learn how to perform TSPITR using RMAN